In various areas and for a number of problems and tasks in various applications, it is often the case that allocations between objects to be managed by the corresponding applications have to be changed. Thus, the situation may for example arise in the area of insurance, e.g., on account of the retirement or death of an insurance writer, that the business objects managed on the part of this insurance writer have to be transferred to one or more other insurance writers; in this case, it would be an inventory transfer that has to be effected. In the area of insurance, it is similarly possible that a transfer of claims and/or liability from a commission contract to one or more other commission contracts becomes necessary on account of specific events. Similar scenarios are also conceivable in other fields of business, which are always associated with a necessary object allocation.
There are a number of factors that can influence an allocation process to be carried out and that can therefore greatly increase its complexity. In the environment of a change of object relationships further process steps may, for example, become necessary. These may include preparatory, follow-up, fault-handling or checking activities in relation to object allocations. Thus, it may for example happen that in the course of an allocation process, checks by one or more clerks or officials, the drafting or amendments of a contract, such as for example a commission contract, or the printout of correspondence are necessary. Preparatory, allocatory, checking, fault-handling and follow-up steps in an allocation process need not in this connection necessarily take place sequentially, and there may be dependencies between process steps. It might for example be desired that an inventory transfer can be carried out only after a successful claim and liability transfer.
An allocation process is also not restricted to an allocation type, such as for example an inventory transfer and a claim and liability transfer, or to an application, and need not be restricted to one system. Instead, various mutually independent systems may be affected by an allocation process to be carried out or may influence such a process.
An allocation process may contain a number of allocation types and may comprise a number of preparatory, checking, allocatory, fault-handling and follow-up process steps. In addition, complex relationships may exist between the individual allocation process steps. As already explained, a number of various applications possibly implemented on various systems may furthermore be involved in an allocation process. Finally, the number of objects to be allocated, i.e., the allocation volume, may also be very large. All of these factors can greatly increase the complexity of an allocation process, which makes it necessary or desirable to have a system-side support in the implementation of such an allocation process in one or more applications.